This invention relates to increasing a computer system""s protection of system software, other software, and data from unauthorized, improper, or incorrect modification by an end developer or other software or agents, for example by checking or monitoring of information, such as authorization code data.
Interconnectivity frequently requires new code in legacy applications, typically COBOL on mainframe computers, or new interface or client applications interfacing with existing legacy applications, frequently customized interfaces on proprietary versions of SQL servers. The very process of applying the new code to a base or legacy application may corrupt either the program code or the stored data, and the legacy or base application, because of a mismatched tool or add-on.
For example, in opening, editing, and saving, by way of illustration only and not limitation, COBOL files, a new tool designed for a newer COBOL version, may open up the target COBOL file written and compiled using an earlier version of COBOL, read the target COBOL file into the development tool, and inadvertently convert the target COBOL file from the old version to the new version upon saving. This mismatch totally corrupts the now saved COBOL file. Another example arises when the development tool encounters IBM EBCDIC COBOL (extended binary-coded decimal interchange code), converts it to ASCII, applies the changes using a later version of COBOL, and reconverts the changed file back to EBCDIC with disastrous results. Unfortunately, industry standard conversion programs allow different operating systems to change a file from one code to another, as EBCDIC COBOL 85 to ASCII COBOL 85 to ASCII COBOL 97 to EBCDIC COBOL 97, to run on an EBCDIC COBOL 85 platform, and now with overwriting of one or more of the sequence area, the indicator area, area a (columns 8-11), area b (columns 12-72), or the label area, introducing unrecognized commands, improper data types, line wrap or other artifacts or errors.
Exemplary errors and artifacts that can be inadvertently introduced include ignoring or disregarding the column dependency and fixed zones of COBOL, omitting sections required by the target version of COBOL, entering improper data, or accepting incorrect, editor suggested, defaults in the required COBOL sections (Identification, Program ID, Environment Division). Still other errors include syntactical errors and formatting errors from one version of the target COBOL file to the incorrect version of COBOL supported by the development tool. Still other sources of file corruption include entering reserved words (commands) that differ from one COBOL version to another.
How this happens is shown in FIG. 1, which illustrates a legacy file 101 being edited by an integrated development environment (xe2x80x9cIDExe2x80x9d) including a development tool, 103. The legacy file 101, represented in the FIGURE as an S/390 DBMS SQL file 101 has one set of concatenation commands, character string extraction commands, data type conversions, aliases, and the like. These particular SQL functions are among the set of SQL functions that differ between versions of SQL. The file 101 is exported to a Unix workstation with an Integrated Development Environment (IDE) 103 that supports a different version of SQL. The S/390 DBMS SQL file 101 is modified, and returned from the work station with another, different set of concatenation commands, character string extraction commands, data type conversions, and aliases. These commands and functions are proper for a different version of a DBMS, but not for the DBMS version 101 residing on the S/390 platform.
Similar kinds of errors or file corruption are just as likely in writing applications to the various versions of SQL and DBMSs. Typically, an application program runs as a plug-in or application on top of a DBMS. As used herein xe2x80x9cplug-inxe2x80x9d applications, which may be tools, are programs that can easily be installed and used as part of a base program. A plug-in application is recognized automatically by the base program and its function is integrated into the target file that is being presented. The program or plug-in could be an order entry program, an inventory management program, a financial program, a CRM program, or the like. When there is a need to port the application program to a different version of SQL running on a different DBMS, the differences between frequently used commands in modern versions of SQL running on different DBMSs can wreak havoc throughout the enterprise. One version of SQL may use a plus sign for concatenation while the other version of SQL use two pipes for concatenation; there may be differences in one or more of creating column name aliases, extracting part of a character string, performing data type conversions, returning a number""s ceiling, getting a current date or the next day""s date. Still other problems include operations within a GROUP_BY, improper JOINs, table aliases with and without AS, the use of FROM and FROM following DELETE, the CREATE_TABLE syntax, the use of NULL and NOT_NULL, ALTER_TABLE rules and implications, DROP_TABLE rules and implications, the use or non-use of ORDER_BY in VIEWs, SAVEPOINT creation and use, and ranges (minimum values, maximum values, ranges, data types, user defined data types).
For example, in the case of savepoints, one DBMS""s SQL establishes savepoints by:
SAVEPOINT delete1
. . .
ROLLBACK delete1
while another DBMS""s SQL establishes savepoints by
SAVE TRANSACTION delete1
. . .
ROLLBACK TRANSACTION delete1
Vastly different code is used to achieve the same result, and this is not anomalous or atypical. It is a real world problem faced by real world programmers every day. For this reason, platform owners developing new applications, for example, e-business applications, based upon or interfacing with legacy systems, as well as systems running on disparate platforms, are challenged with the need to protect the base legacy system (or other host systems) from corruption, and to uniquely identify and associate various file types and artifacts from multiple disparate platforms with the appropriate integrated development environments (IDE), viewers, editors and transformation tools compatible with the characteristics and attributes of those objects. Use of the wrong integrated development environments, viewers, editors and transformation tools can lead to corruption of files and loss of data.
Thus, a clear need exists to enable a platform owner to protect their software assets from corruption.
According to the method, system, and program product of our invention, target applications, typically, legacy applications, and the data resident therein, is protected from corruption and even destruction by comparing and matching a repository of target file attributes (target file metadata) and development environment, viewer, editor, or transformation tool capabilities (development tool metadata).
This is accomplished through the method, system, and program product of our invention, which provide for accessing a target file with a potentially corrupting development tool. The target file is characterized by its attributes, and the development tool is characterized by its tool capabilities, including the capability to return the target file with possibly harmfully changed attributes. Protecting target file attributes from harmful change is accomplished by limiting development tool access to the target file if the development tool capabilities mismatch target file attributes. This is achieved by determining target file attributes from a source of target file attribute information. The source of target file information is chosen from, for example, target file header information, a repository of target file attributes, an associated DTD file, or an encapsulating XML file. The actual determination of access is done by matching target file attributes to tool capabilities and granting development tool access to the target file if there is a match of target file attributes and tool capabilities, and denying or limiting access if there is a mismatch. A further step is assigning a registration permission key tool to the development tool if the development tool capabilities match the target file attributes.
Target file access is granted or denied based on matches or mismatches of target and development tool metadata elements. Each platform owner may have a unique registration of their file types and artifacts based upon developer access/authorization as well as which tools (integrated development environments, viewers, editors, transformation, etc) may act upon the file types and artifacts. In this way, when a development tool requests access to a target application, the development tool""s capabilities (development tool metadata) are compared to the target""s attributes (target metadata), and access is authorized based upon a match of the tool metadata with target metadata. Additionally, the access/authorization can be recorded, for example, on the platform or the development tool, as a Registration Permission Key. The access/authorization depends upon a proper match of target file attributes and development tool capabilities. Access/authorization is communicated back to the development tool which initiated the request, typically, a workstation based IDE.
The method, system, and program product of the invention provide a way to let the platform owner uniquely: (1) register the category of developers who can access certain file types and resources and in what capacity (e.g. None, Read-Only, Read-Write, Execute-Only), (2) register any attributes, including characteristics and platform-specific information, of the file types and resources which must be adhered to (e.g. Fixed record length) or communicated back, (3) register any restrictions regarding what type of computer programs can operate on the file types and resources (e.g. introduce a category for tools so that future tools which belong to this category can be considered as potential candidate tools which may operate against this file type); likewise, this category also can indicate that this file type will not accept future tools unless designated by an administrator within the platform owner""s company, and (4) register any associations to specific tools or command files (e.g. a specific JCL for compilation or a specific JCL for linking, etc.) as well as specific invocation options for those tools.
In a further embodiment of our invention an end user can create a new or derivative file that inherits file characteristics from file type data in the repository. In this aspect of the invention, repository metadata functions as a template or style sheet, and, in combination with one or more of an integrated development environment, a an editor, a complr, a syntax editor, or parser, created a system compatible file with inherited characteristics and attributes.
Additionally, as noted above, access/authorization for a particular development tool/target combination or for a particular developer/development tool/target combination, can be recorded, for example, on the platform or the development tool, as a Registration Permission Key. This registration task may be performed by an administrator or someone who has the proper authorization and familiarity with the target system/platform.
By providing a mechanism to allow the platform owner to uniquely register development tool access and developer access to each of their platform""s file types and artifacts, it is possible to minimize the possible corruption of files and loss of data through accidental usage of the wrong viewers, editors, transformation tools or through non-authorized access. According to the invention tool and developer access is based upon individual developer access, tool and file attributes and characteristics, platform specifications, restrictions, options, etc.
Typically, the method is carried out on a development platform having a development tool, text editor, or integrated development environment, using a program product containing program code that directs, configures, and controls the development platform. A program product is a storage medium, as a hard drive, a CD-ROM, a tape, floppy discs, or the like, containing computer readable code to direct a computer to perform a task.